


RESPONSE.FOG
Steven Greenberg, 10 May 1987

This  is in response to a file being circulated, STANDARD.FOG,  issued
by Gale Rhoades and the FOG office staff.  While I understand the need
for  the document and the intent of it, I feel that  certain  sections
disseminate  information  which is misdirected,  misleading,  or  just
plain  technically incorrect.  If you are not familiar with the  docu-
ment,  it  is a series of guidelines which must be used if one  is  to
consider making a submissions to FOG  [Ref. #2].

Since  the  inception of CRUNCH, I have witnessed a  wide  variety  of
reactions, from very positive to quite negative.  Reasons for "opposi-
tion" to CRUNCH have ranged from plain closed-mindedness to some  very
real  questions  the  of "standards"  and  intersystem  compatibility.
Standards  are very important, and they don't change overnight.   Each
system  or person has a right to decide what is or  isn't  "standard",
and, based on that, form appropriate guidelines.  CRUNCH has gone from
a relatively unknown compression format to quite a popular one.  While
it is now arguably a standard of some kind, the final decision on that
question is of course left to the user.

I don't really care if FOG condones or condemns CRUNCH.  It was  writ-
ten  for  my own interest and for the many others who find  it  useful
(though  I  did  make  $15 on it-  an  unsolicited  contribution  from
England!).  I am not in the habit of getting involved in these contro-
versies,  such as the recent PRACSA discussions concerning the  "sanc-
tioning"  of crunched files (see Ref #1 below).  I am responding  now,
however,  specifically to this FOG document, because it makes  several
points which I find offensively inaccurate.

Quote from STANDARD.FOG:

|   "Things  to Avoid:  These are the things which have  caused  major
|   problems, especially lately."
|
|   "1. ALL crunch programs.  These programs are changing dramatically
|   nearly every week.  In most cases, files which were crunched by  a
|   later version cannot be extracted by an earlier version."

There  have  only been two crunched file formats in  all  of  history,
namely  "1" and "2".  If there still are any type "1"  files  floating
around, they would be uncrunched by any v2 program with absolutely  no
problem.  The standard current version of CRUNCH, (v2.3), was released
with  full source code in November of '86.  The statements above  not-
withstanding,  there have been no additional releases (or known  bugs)
in the twenty-five or so weeks since, nor has v2 format changed  since
it  was first introduced some 36 weeks ago.  There have been  quite  a
number of support releases from other authors (see partial listing be-
low),  and all work with the same v2 format originally  introduced  in
early September, 1986.



                                  1



STANDARD.FOG continues:

|   "Files  which contain a "Z" as the second character in the  exten-
|   sion  will  be discarded until (unless) the  various  authors  can
|   agree  on some standards and build RELIABLE and easy-to-use  prog-
|   rams which allow a CP/M user to extract a file crunched on an  MS-
|   DOS  system, an MS-DOS user to extract a file crunched on  a  CP/M
|   system  AND  both  CP/M  and MS-DOS  users  to  create  compatible
|   crunched files."

Discarded indeed! (watch your .AZM files!)

Ironically, I feel it appropriate to congratulate the various  authors
of  CRUNCH  / UNCR type programs, as well as various  TYPE  and  other
utilities  which support the crunched file format.  Each of these pro-
grammers  have conscientiously followed the existing format.  We  have
thus evolved a system where all these programs ARE in fact compatible-
I  have no explanation for the statements made in the above  paragraph
concerning "agree[ment]" and "RELIABILITY" (emphasis theirs.. why?).

Using UNCR or equiv., CP/M users CAN extract files made on any  system
which  could create them.  MS-DOS users CAN reliably extract  crunched
files  created  on CP/M systems (see Ref #1 below).   Of  course  CP/M
users CAN create them, in a multitude of ways.  At this moment, MS/DOS
users  cannot CREATE a crunched file, but then again neither can  CP/M
users  create an ARC file right now.  These inabilities are  temporary
and  of secondary importance; the paramount issue is that everyone  be
able to reliably access the information contained in compressed files.

Consider  the  following list, which contains as many  programs  as  I
could  think  of offhand which directly deal with  the  crunched  file
format.  ALL ARE COMPATIBLE.


Program    OS     Function              Author(s)            Notes
=======   ====    ========              ==========           =====
CRUNCH23  CP/M    Crunch, Uncr, Docs    Steven Greenberg     w/ Z-80 source
FCRNCH11  CP/M    CR, UCR, many xtras   Charles Falconer     w/ 8080 source
TYPELZ2x  CP/M    TYPE facility         Steve G./Others      Frm LBR's, etc.
LTxx      CP/M    TYPE & extras         Charles Falconer     Can extract to dsk
TYPEQZxx  CP/M    TYPE w/ wildcards     John Hastwell-Batton Recognizes ASCII
TXxx      CP/M    another TYPER         Harris Landsberg     Strange language
UNCR231   ['C']   UNCR only, portable   Frank Prindle        Compilations below
UNCR232   MS/DOS  Compiled ver of abv   Prindle/ Hansen      See  Ref. #1
UNCR-DOS  MS/DOS  Compiled ver of abv   Prindle/ Greenberg   Similar to above
JETFIND   CP/M 2  Advanced string srch  Bridger Mitchell     $Commercial Prgm
TRSCRNCH  TRS     For New TRSDOS 80     Jon Saxton / Others  From Australia
UNCRNCHR  MAC     New, runs on MACS     Prindle/Beard        New for MAC
CR23D     CP/M    Datestamper support   Bridger Mitchell     In Beta Test

Additional related programs are now being worked on in Canada,
England, and elsewhere.

===============================================================================


                                  2



Another excerpt from STANDARD.FOG:

|   "I have yet to see a correctly named file which will not unsQueeze
|   with NSWP."

Well  I,  for one,  have a number of them.  On 23 Feb.  '85,  Paul  J.
Homchick  wrote  a  proposed standard explaining  how  and  why  files
squeezed  by  some MS-DOS programs were incompatible, along  with  his
proposed  solution. Here is an excerpt from P. Homchick's  SQDATE.DOC,
referring to MS-DOS squeezers with names SQ2 and ZSQ:

    "Although  SQ2 added time and date stamping, it did so at the  ex-
    pense  of downwards compatibility.  A file squeezed with the  time
    and  date mode of SQ2 could ONLY be unsqueezed with the  companion
    unsqueezer USQ2 (or ZUSQ).  Thus the advantage of  standardization
    was lost.  No file squeezed with SQ2 could be unsqueezed with  the
    older standard programs or moved to CP/M or UNIX systems.   Clear-
    ly,  SQ2 created a number of unfortunate consequences  along  with
    its time and date stamping."

----------------------------------------------------------------------

An  aside,  not related to file compression:  The  list  of  "approved
filename characters" includes four characters specifically NOT allowed
by  DRI for CP/M 3.0, namely "(", ")", "-" and "!".   The  exclamation
mark,  in particular, is an odd inclusion insofar as it  is  virtually
impossible to create or work with a filename containing that character
in CP/M 3.

======================================================================

                          APPENDIX: "Ref #1"

Here  is "Ref #1" mentioned several times above.  These  are  messages
left  on the PRACSA board, sort of a culmination of a  previously  on-
going debate.  I include them here for general reference and especial-
ly for the author(s) of STANDARD.FOG.

-----
Area: MS-DOS
Msg # 179 04/10/87 11:08 PDT
Subj: UNCRunching via MS-DOS
From: Irv Hoff
To:   All

The following list is the result of an extensive test that John  Allen
did  with his MS-DOS computer using the uncrunch program  UNCR232.EXE.
All  the  xxxx.?Z? files were downloaded from a CP/M-80  RCPM  system.
John  says they all uncrunched fine, without loss of any  information.
MS-DOS owners can user the UNCR232.EXE program without hesitation  for
files crunched on CP/M-80 equipment using CRUNCH.


                                  3



 BEFORE:
 ------
 -BYE5KMD NZW    7-13-86  NZW    415BBS   TZT    BBS-USA  TZT
 BGIIFACT TZT    FIFTH    TZT    TRAGEDY  TZT    ULTRA    TZT
 USR9600  TZT    AJCBR    LZT    AJVAC    LZT    NOVBEST  LZT
 OCTBEST  LZT    PDFT0487 LZT    RCPM0387 LZT    ZNODES40 LZT
 ZNODES41 LZT    CREDIT   DZC    OZBYE510 DZC    SNOOPY87 CZL
 VICTORY  FZC    WRITE    IZ     EXCHANGE PZP    UP2DATE  PZP

 AFTER:
 -----
 -BYE5KMD NEW    7-13-86  NEW    415BBS   TXT    BBS-USA  TXT
 BGIIFACT TXT    FIFTH    TXT    TRAGEDY  TXT    ULTRA    INF
 USR9600  TXT    AJCBR    LST    AJVAC    LST    NOVBEST  LST
 OCTBEST  LST    PDFT0487 LST    RCPM0387 LST    ZNODES40 LST
 ZNODES41 LST    CREDIT   DOC    OZBYE510 DOC    SNOOPY87 CAL
 VICTORY  FCC    WRITE    IN     EXCHANGE PCP    UP2DATE  PCP

These files came from B0: of the PRACSA RCPM and were uncrunched using
UNCR232.EXE on a MS-DOS computer by John Allen of the PRACSA standards
committee.   All  parts  of the files were normal and  in  the  proper
place.   These  files ranged from rather short to pretty  long.   They
were  more  than adequate to establish the fact  that  UNCR232.EXE  is
doing its job correctly.

UNCR232.EXE should be in the library of any MS-DOS user that frequents
RCPM systems that might have crunched files with xxxx.?Z? extents.  It
is available on G0: of the PRACSA RCPM.

-----
Area: PRACSA
Msg # 219 04/13/87 22:39 PDT
Subj: crunch
From: Al Mehr
To:   All

I capitulate.  The "uncruncher" for DOS seems 100%. As I don't support
MAC  or APPLE stuff on my board, do not know what they will do, but  I
now  agree, CRUNCH is certainly an acceptable alternative. I  withdraw
all my objections for using crunch files on the PRACSA BBS.

   Al Mehr     SERVU

----------------------------------------------------------------------
Ref #2:   The actual document,  STANDARD.FOG,  a file uploaded by Gale
Rhoades, is available on the PRACSA RCP/M as "STANDARD.FZG".
----------------------------------------------------------------------




                                  4
